From jim_pruyne at hp.com Wed Apr 5 00:57:05 2006 From: jim_pruyne at hp.com (Jim Pruyne) Date: Wed, 05 Apr 2006 00:57:05 -0500 Subject: [graap-wg] telecon on 4/5 Message-ID: <44335C31.5070500@hp.com> We will have a telecon. on Wed. morning/evening. Dial-in numbers will be the same. The time in the US will remain the same, but the US has changed to daylight savings time over the weekend. I believe this gives us the times:: 9:00AM Central Daylight Time US (UTC-5) which should be: 10:00AM Eastern Time US 1500 UK 1600 Germany (I believe this is the time now that US & EU are both on daylight) 2300 Japan 2100 Thailand Phone Number: 866-673-8466 in the US. 702-477-6031 for those outside the US. Conference code #8578310. We'll attempt to complete the discussion of the terminate based on Toshi's drafts, and continue with other open issues. We'll also discuss whether people will be available at the same time of day on Fri. to continue discussions. --- Jim From t-nakata at cw.jp.nec.com Wed Apr 5 03:56:40 2006 From: t-nakata at cw.jp.nec.com (Toshiyuki Nakata) Date: Wed, 5 Apr 2006 17:56:40 +0900 Subject: [graap-wg] telecon on 4/5 In-Reply-To: <44335C31.5070500@hp.com> Message-ID: <000001c6588e$dc9ced30$ab84380a@ISIBASI> > Phone Number: 866-673-8466 in the US. 702-477-6031 for those > outside the US. > Conference code #8578310. > > We'll attempt to complete the discussion of the terminate > based on Toshi's drafts, and continue with other open issues. > We'll also discuss whether people will be available at the > same time of day on Fri. to continue discussions. > PDF version of the Temination Related Parts as I think the Gridforge version does not include this part Best Regards 1)Apologies for Japanese fonts. 2)If people have trouble trying to read it, please let me know. Best Regards Toshi ----- Toshiyuki Nakata ?????? Executive Chief Engineer, Central Research Lab. NEC 1753, Shimonumabe, Nakahara-Ku, Kawasaki,Kanagawa 211-8666,Japan Tel +81-44-431-7653 (NEC Internal 22-60035) Fax +81-44-431-7609 (NEC Internal 22-60509) > --- Jim > > -------------- next part -------------- A non-text attachment was scrubbed... Name: WS-AgreementSpecification(Terminatespecific).pdf Type: application/pdf Size: 169211 bytes Desc: not available Url : http://www.ogf.org/pipermail/graap-wg/attachments/20060405/8f857cb7/attachment.pdf From jim_pruyne at hp.com Wed Apr 5 10:12:30 2006 From: jim_pruyne at hp.com (Jim Pruyne) Date: Wed, 05 Apr 2006 10:12:30 -0500 Subject: [graap-wg] minutes from 4/5 telecon Message-ID: <4433DE5E.1070002@hp.com> Are attached. Note that the next call will be on Friday, 4/7, at the usual time of day. Reminder announcement to follow. --- Jim -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: Apr0506-minutes.txt Url: http://www.ogf.org/pipermail/graap-wg/attachments/20060405/d4c25f08/attachment.txt From nakata at mtg.biglobe.ne.jp Wed Apr 5 10:58:27 2006 From: nakata at mtg.biglobe.ne.jp (Toshiyuki Nakata) Date: Thu, 06 Apr 2006 00:58:27 +0900 Subject: [graap-wg] minutes from 4/5 telecon In-Reply-To: <4433DE5E.1070002@hp.com> References: <4433DE5E.1070002@hp.com> Message-ID: <4433E923.4030709@mtg.biglobe.ne.jp> Hi Jim: There is one editing error I made in P.36 Line 4-5 Could you please change These cases can be handled by this by allowing a domain-dependent sub-state of Terminated to indicate a normal completion prior to termination completion. =>(to) These cases can be handled by allowing a domain-dependent sub-state of Terminated to indicate a normal completion prior to termination completion. (ie delete the redundant 'by this')? Sorry for the trouble. Best Regards Toshi Jim Pruyne wrote: > Are attached. Note that the next call will be on Friday, 4/7, at the > usual time of day. Reminder announcement to follow. > > --- Jim > > From jim_pruyne at hp.com Wed Apr 5 11:03:48 2006 From: jim_pruyne at hp.com (Jim Pruyne) Date: Wed, 05 Apr 2006 11:03:48 -0500 Subject: [graap-wg] minutes from 4/5 telecon In-Reply-To: <4433E923.4030709@mtg.biglobe.ne.jp> References: <4433DE5E.1070002@hp.com> <4433E923.4030709@mtg.biglobe.ne.jp> Message-ID: <4433EA64.3010705@hp.com> Done, the updated version with this change will be uploaded in a moment. --- Jim Toshiyuki Nakata wrote: > Hi Jim: > There is one editing error I made > in P.36 > Line 4-5 > Could you please change > > These > cases can be handled by this by allowing a domain-dependent sub-state of > Terminated to indicate a normal completion prior to termination > completion. > =>(to) > > These > cases can be handled by allowing a domain-dependent sub-state of > Terminated to indicate a normal completion prior to termination > completion. > > (ie delete the redundant 'by this')? > Sorry for the trouble. > > Best Regards > Toshi > > > Jim Pruyne wrote: >> Are attached. Note that the next call will be on Friday, 4/7, at the >> usual time of day. Reminder announcement to follow. >> >> --- Jim >> >> > From karlcz at univa.com Wed Apr 5 23:29:09 2006 From: karlcz at univa.com (Karl Czajkowski) Date: Thu, 6 Apr 2006 11:29:09 +0700 Subject: [graap-wg] minutes from 4/5 telecon In-Reply-To: <4433DE5E.1070002@hp.com> References: <4433DE5E.1070002@hp.com> Message-ID: <20060406042909.GG21161@moraine.localdomain> On Apr 05, Jim Pruyne modulated: > - On updated termination diagram: > * Asit to send a note on the mailing list to verify that we really > have a transition from PendingAndTerminating to > ObservedAndTerminating. None of us seem to be able to come up with > a message sequence that would cause that to happen. I think this transition is implied by Toshi's "broker" example, unless we assert that there is some sort of transactional semantics in the protocol? If you make an offer to a broker, and it is pending in the broker because he has started to make offers to other service managers, your terminate request MAY arrive during the hazard window where the broker has started making commitments but has not received accepts from the subsidiary services yet. The client-to-broker agreement changes state to pending-terminating, and the broker can attempt to terminate the subsidiary agreements. However, depending on whether they terminate before or after they are accepted, the broker may want to communicate this "distributed acceptance" transition that occurred during the termination phase. I assume this has impact and is important to model in the event that the "penalties" are different depending on whether termination occurs before or after acceptance. The fundamental issue is that with pending agreements, the initiator has already committed in his offer message and he is at the mercy of the responder to decide if a termination request occurs before or after acceptance. Because of these hierarchical and asynchronous agreement scenarios, I think we have to make the termination request interaction also be asynchronous. Just as with the acceptance/rejection window, there is a window between when the termination request is received and the outcome is known. We can either delay the response, or model the uncertain intermediate state in the agreement state. I think we should do the latter to be consistent with how we have handled the acceptance/rejection window. For consistency, perhaps we should even go so far as to introduce two terminate request variants? One that is synchronous and delays the response, and one that responds early but leaves the agreement in an uncertain state? karl -- Karl Czajkowski karlcz at univa.com From asit at us.ibm.com Thu Apr 6 09:41:54 2006 From: asit at us.ibm.com (Asit Dan) Date: Thu, 6 Apr 2006 10:41:54 -0400 Subject: [graap-wg] minutes from 4/5 telecon In-Reply-To: <20060406042909.GG21161@moraine.localdomain> Message-ID: Karl, It is understood that receiving a termination message (and upon provider acknowledgement), i) an agreement state transitions from a "Pending" to "PendingAndTerminating", and ii) the termination of service/agreement is not instantaneous (as you have elaborated). What we are trying to resolve here are the semantics of the states "PendingAndTerminating" and "ObservedAndTerminating", i.e., what are the obligations in delivering (service and) service quality, while an agreement is being terminated. Clearly, the options are a) No further obligations in delivering service quality (these states explicitly capture start of termination process, and the only difference between the above two states are historical, i.e., the state at which the termination message is received). b) Degraded quality of service (what are "observing"? Just how bad is it during termination process? Does client still expects any service quality? Are the BV specifications, i.e., penalties or preferences the same? Obvioulsy, further semantics has to be defined for specific domains for this to be meaningful.) and, c) Full quality of service, i.e., acknowledges start of termination process, but remains undefined when this will terminate, and service quality is fully observed. Again, we need more detailed specification to make sure there is a limit to this termination process, and/or, different BV assertions during this process. I think the simplest semantics (that doesn't require any further specification) is to assume upon starting the termination process the service quality obligations are no longer valid and observed. There is no easy way to have a consistent state across multi-tier services, i.e., where a service may depend on other autonomous services (as defined by its own set of agreements). Many years back, in the transaction community(HPTS), I argued for COYOTE (Cover Yourself Transaction Environment) principles, where service implementation and management issues are hidden from a client, even when a service is dependent on other services. The attached paper illustrates these principles. As a matter of fact, to further simplify the agreement states according to the above principles, we should assume termination of agreement (and not necessarily provider cleaning up and bookkeeping) is instantaneous, i.e., receiving the termination message takes the agreement state from "Pending" or "Observed" to "Terminated" state. In any case, if we choose the other two options, we have to specify further details in WS-Agreement specification for this transition to be meaningful. Regards. Asit Dan, Ph.D. SWG SOA Design Requirements Phone: (914) 766-1767 Internet: asit at us.ibm.com ICSOC 06 PC Chair (http://www.icsoc.org) Karl Czajkowski Sent by: owner-graap-wg at ggf.org 04/06/2006 12:29 AM To Jim Pruyne cc GRAAP-WG Subject Re: [graap-wg] minutes from 4/5 telecon On Apr 05, Jim Pruyne modulated: > - On updated termination diagram: > * Asit to send a note on the mailing list to verify that we really > have a transition from PendingAndTerminating to > ObservedAndTerminating. None of us seem to be able to come up with > a message sequence that would cause that to happen. I think this transition is implied by Toshi's "broker" example, unless we assert that there is some sort of transactional semantics in the protocol? If you make an offer to a broker, and it is pending in the broker because he has started to make offers to other service managers, your terminate request MAY arrive during the hazard window where the broker has started making commitments but has not received accepts from the subsidiary services yet. The client-to-broker agreement changes state to pending-terminating, and the broker can attempt to terminate the subsidiary agreements. However, depending on whether they terminate before or after they are accepted, the broker may want to communicate this "distributed acceptance" transition that occurred during the termination phase. I assume this has impact and is important to model in the event that the "penalties" are different depending on whether termination occurs before or after acceptance. The fundamental issue is that with pending agreements, the initiator has already committed in his offer message and he is at the mercy of the responder to decide if a termination request occurs before or after acceptance. Because of these hierarchical and asynchronous agreement scenarios, I think we have to make the termination request interaction also be asynchronous. Just as with the acceptance/rejection window, there is a window between when the termination request is received and the outcome is known. We can either delay the response, or model the uncertain intermediate state in the agreement state. I think we should do the latter to be consistent with how we have handled the acceptance/rejection window. For consistency, perhaps we should even go so far as to introduce two terminate request variants? One that is synchronous and delays the response, and one that responds early but leaves the agreement in an uncertain state? karl -- Karl Czajkowski karlcz at univa.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.ogf.org/pipermail/graap-wg/attachments/20060406/e6b3566c/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: hpts97.pdf Type: application/octet-stream Size: 1076364 bytes Desc: not available Url : http://www.ogf.org/pipermail/graap-wg/attachments/20060406/e6b3566c/attachment.obj From karlcz at univa.com Thu Apr 6 10:39:14 2006 From: karlcz at univa.com (Karl Czajkowski) Date: Thu, 6 Apr 2006 22:39:14 +0700 Subject: [graap-wg] minutes from 4/5 telecon In-Reply-To: References: <20060406042909.GG21161@moraine.localdomain> Message-ID: <20060406153914.GY21161@moraine.localdomain> On Apr 06, Asit Dan modulated: > > Karl, > It is understood that receiving a termination message (and upon > provider acknowledgement), i) an agreement state transitions from a > "Pending" to "PendingAndTerminating", and ii) the termination of > service/agreement is not instantaneous (as you have elaborated). > > What we are trying to resolve here are the semantics of the states > "PendingAndTerminating" and "ObservedAndTerminating", i.e., what are > the obligations in delivering (service and) service quality, while an > agreement is being terminated. Clearly, the options are > > a) No further obligations in delivering service > quality (these states explicitly capture start of termination process, > and the only difference between the above two states are historical, > i.e., the state at which the termination message is received). I think there is another semantics of concern about the implied obligations, i.e. the "payment" or "penalties". Let us assume in all cases that no service delivery guarantees will be expected once the client sends the terminate request. The issue I am trying to raise is that it is not just an atomic "state at which the termination is received". If I, as a broker, am in the process of computing acceptance when the termination is received, I would like to reserve the right to decide LATER whether I had accepted or rejected the agreement. I cannot make this decision instantaneously but must synchronize with a potentially complex brokering process. If allowed to by the specification, I could return immediately with the state I know (PendingAndTerminating) and still would be able to enter other states to reflect what happened. So, PendingAndTerminating->ObservedAndTerminating->Terminated would mean that I have decided, due to the non-deterministic things I was doing as a broker, that I was not able to complete your terminate request before accepting. I will bill you as having terminated an accepted agreement, i.e. in order to cover my own obligations with the services I was brokering (who may have accepted my offers before I could request termination). On the other hand, PendingAndTerminating->Terminated would mean that I have decided that I was able to complete your terminate request before accepting. I will bill you as having terminated a pending agreement, i.e. I do not have to cover obligations with brokered services because I either terminated them early or never even got around to making offers. The issue is that at the time I, the broker, receive your terminate request I do not really know the distributed state of my own brokering process and I cannot tell you whether I will have to go into ObservedAndTerminating or not. So, if we do not allow the PendingAndTerminating->ObservedAndTerminating transition, then I cannot respond to show any "terminating" state until I am able to synchronize my distributed process and make this determination. If you buy any of this, I think there is also an issue of having distinct final states (maybe sub-states?) for Terminated to encode the history of whether the agreement had been accepted or not. karl -- Karl Czajkowski karlcz at univa.com From asit at us.ibm.com Thu Apr 6 13:41:30 2006 From: asit at us.ibm.com (Asit Dan) Date: Thu, 6 Apr 2006 14:41:30 -0400 Subject: [graap-wg] minutes from 4/5 telecon In-Reply-To: <20060406153914.GY21161@moraine.localdomain> Message-ID: Karl, very interesting. You are suggesting semantics of "PendingAndTerminating" and "ObservedAndTerminating" are identical to their counterparts (i.e., "Pending" and "Observed", respectively), in all aspects other than the acknowledgement of receiving a termination request. As a matter of fact once the termination decision is reached by the provider, the agreement state will transition from either of these states to "Terminated" state immediately (while internal clean up may be taking place). This also means if the termination request is rejected, then the states revert back to their counterpart states. With this interpretation, a transition is possible from "PendingAndTerminating" to "ObservedAndTerminating" until the termination decision is reached. Furthermore, in "ObservedAndTerminatating" state, the service quality must be observed just as in "Observed" state. If we agree with this interpretation, I can add new transitions from "PendingAndTerminating" and "ObservedAndTerminating" to their counterparts. We also need new text to clarify the transitions from these states to "Terminated" -- triggered by when termination decision is made, (and not when internal clean up may be taking place). Karl Czajkowski wrote on 04/06/2006 11:39:14 AM: > > > I think there is another semantics of concern about the implied > obligations, i.e. the "payment" or "penalties". Let us assume in all > cases that no service delivery guarantees will be expected once the > client sends the terminate request. > > The issue I am trying to raise is that it is not just an atomic "state > at which the termination is received". If I, as a broker, am in the > process of computing acceptance when the termination is received, I > would like to reserve the right to decide LATER whether I had accepted > or rejected the agreement. I cannot make this decision > instantaneously but must synchronize with a potentially complex > brokering process. If allowed to by the specification, I could return > immediately with the state I know (PendingAndTerminating) and still > would be able to enter other states to reflect what happened. > > So, PendingAndTerminating->ObservedAndTerminating->Terminated would > mean that I have decided, due to the non-deterministic things I was > doing as a broker, that I was not able to complete your terminate > request before accepting. I will bill you as having terminated an > accepted agreement, i.e. in order to cover my own obligations with the > services I was brokering (who may have accepted my offers before I > could request termination). > > On the other hand, PendingAndTerminating->Terminated would mean that I > have decided that I was able to complete your terminate request before > accepting. I will bill you as having terminated a pending agreement, > i.e. I do not have to cover obligations with brokered services because > I either terminated them early or never even got around to making > offers. > > The issue is that at the time I, the broker, receive your terminate > request I do not really know the distributed state of my own brokering > process and I cannot tell you whether I will have to go into > ObservedAndTerminating or not. So, if we do not allow the > PendingAndTerminating->ObservedAndTerminating transition, then I > cannot respond to show any "terminating" state until I am able to > synchronize my distributed process and make this determination. > > If you buy any of this, I think there is also an issue of having > distinct final states (maybe sub-states?) for Terminated to encode the > history of whether the agreement had been accepted or not. > > Regards. Asit Dan, Ph.D. SWG SOA Design Requirements Phone: (914) 766-1767 Internet: asit at us.ibm.com ICSOC 06 PC Chair (http://www.icsoc.org) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.ogf.org/pipermail/graap-wg/attachments/20060406/6c2faa1d/attachment.html From asit at us.ibm.com Thu Apr 6 14:08:06 2006 From: asit at us.ibm.com (Asit Dan) Date: Thu, 6 Apr 2006 15:08:06 -0400 Subject: [graap-wg] minutes from 4/5 telecon In-Reply-To: <4433DE5E.1070002@hp.com> Message-ID: Here is an updated foil with the following changes i) Added an initial transitioning state (that is not exposed to the initiator -- represented by the dashed lines) to clarify that exposed initial states can be "Pending", "Observed" or "Rejected". ii) Added new transitions from "PendingAndTerminating" and "PendingAndObserved" to their counterpart states (i.e., "Pending" and "Observed", respectively) when termination decision is rejected, and service is delivered with observed quality of service. owner-graap-wg at ggf.org wrote on 04/05/2006 11:12:30 AM: > * Asit will do an additional diagram to show the initial states that > may be seen. > Regards. Asit Dan, Ph.D. SWG SOA Design Requirements Phone: (914) 766-1767 Internet: asit at us.ibm.com ICSOC 06 PC Chair (http://www.icsoc.org) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.ogf.org/pipermail/graap-wg/attachments/20060406/1753983a/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: AgreementState3-wz-tn-ad.ppt Type: application/octet-stream Size: 46080 bytes Desc: not available Url : http://www.ogf.org/pipermail/graap-wg/attachments/20060406/1753983a/attachment.obj From t-nakata at cw.jp.nec.com Thu Apr 6 21:35:15 2006 From: t-nakata at cw.jp.nec.com (Toshiyuki Nakata) Date: Fri, 7 Apr 2006 11:35:15 +0900 Subject: [graap-wg] minutes from 4/5 telecon In-Reply-To: Message-ID: <000001c659eb$e87cafb0$ab84380a@ISIBASI> Hi: Asit thank you very much for the foil. I've included it in the updated doc. 1)I've added text OfferReceived is an internal state which is not exposed to the AgreementInitiator. * OfferReceived is an initial transition state (that is not exposed to the initiator -- represented by the dashed lines) to clarify that exposed initial states can be "Pending", "Observed" or "Rejected". It may be redundant to have two consecutive statements with almost the same meaning. If so, please choose which sentence should be dropped. I wasn't sure whether OfferReceived was a first class state. 2)I've added ObservedAndPending in the following statement. The Observed and ObservedAndPending states indicate that both parties are obligated? with respect to the service and guarantee terms of the agreement. 3)In the explanation of Terminated state I've added "when termination decision is made." This state MAY follow Pending, PendingAndTerminating, Observed or ObservedAndTerminating when termination decision is made. 4)I have NOT added OfferReceived to the wsag:AgreementState as I understand OfferReceived is not visible to Agreement Initiator. Best Regards Toshi ----- Toshiyuki Nakata ?????? Executive Chief Engineer, Central Research Lab. NEC 1753, Shimonumabe, Nakahara-Ku, Kawasaki,Kanagawa 211-8666,Japan Tel +81-44-431-7653 (NEC Internal 22-60035) Fax +81-44-431-7609 (NEC Internal 22-60509) > -----Original Message----- > From: owner-graap-wg at ggf.org [mailto:owner-graap-wg at ggf.org] > On Behalf Of Asit Dan > Sent: Friday, April 07, 2006 4:08 AM > To: Jim Pruyne > Cc: GRAAP-WG; owner-graap-wg at ggf.org > Subject: Re: [graap-wg] minutes from 4/5 telecon > > > Here is an updated foil with the following changes > i) Added an initial transitioning state (that is not > exposed to the initiator -- represented by the dashed lines) > to clarify that exposed initial states can be "Pending", > "Observed" or "Rejected". > ii) Added new transitions from "PendingAndTerminating" > and "PendingAndObserved" to their counterpart states (i.e., > "Pending" and "Observed", respectively) when termination > decision is rejected, and service is delivered with observed > quality of service. > > > > > owner-graap-wg at ggf.org wrote on 04/05/2006 11:12:30 AM: > > > * Asit will do an additional diagram to show the initial > states that > > may be seen. > > > > > > > Regards. > Asit Dan, Ph.D. > SWG SOA Design Requirements > Phone: (914) 766-1767 > Internet: asit at us.ibm.com > ICSOC 06 PC Chair (http://www.icsoc.org) > -------------- next part -------------- A non-text attachment was scrubbed... Name: WS-AgreementSpecificationDraft060407(Terminate).pdf Type: application/pdf Size: 179661 bytes Desc: not available Url : http://www.ogf.org/pipermail/graap-wg/attachments/20060407/12cde815/attachment.pdf From jim_pruyne at hp.com Fri Apr 7 01:18:12 2006 From: jim_pruyne at hp.com (Jim Pruyne) Date: Fri, 07 Apr 2006 01:18:12 -0500 Subject: [graap-wg] extra telecon on 4/7 Message-ID: <44360424.3020701@hp.com> We will have a telecon. on FRI. morning/evening. Dial-in numbers will be the same. The time in the US will remain the same, but the US has changed to daylight savings time over the weekend. I believe this gives us the times:: 9:00AM Central Daylight Time US (UTC-5) which should be: 10:00AM Eastern Time US 1500 UK 1600 Germany (I believe this is the time now that US & EU are both on daylight) 2300 Japan 2100 Thailand Phone Number: 866-673-8466 in the US. 702-477-6031 for those outside the US. Conference code #8578310. --- Jim From hludwig at us.ibm.com Fri Apr 7 09:43:21 2006 From: hludwig at us.ibm.com (Heiko Ludwig) Date: Fri, 7 Apr 2006 10:43:21 -0400 Subject: [graap-wg] minutes from 4/5 telecon In-Reply-To: <4433DE5E.1070002@hp.com> Message-ID: Regarding my todo: I didn't get to validating the schema in time prior to the Friday call. However, we do have the TermStateType in the schema. There is no separate GuaranteeTermStateType but a GuaranteeTermStateListType since they always come in lists in our port types. the idea being that, on a domain level, subtypes of different name spaces can be nested in. As to my understanding and as things look to me, this is ok. However, we should verify the whole schema, anyway. Heiko ----- Heiko Ludwig, Dr. rer. pol. IBM TJ Watson Research Center, PO Box 704, Yorktown, NY, 10598 hludwig at us.ibm.com, tel. +1 914 784 7160, mob. +1 646 675 8469 http://www.research.ibm.com/people/h/hludwig/ Jim Pruyne Sent by: owner-graap-wg at ggf.org 04/05/2006 11:12 AM To GRAAP-WG cc Subject [graap-wg] minutes from 4/5 telecon Are attached. Note that the next call will be on Friday, 4/7, at the usual time of day. Reminder announcement to follow. --- Jim Minutes from the April 5, 2006 GRAAP Telecon Attendees --------- Toshi Nakata Jim Pruyne Chris Dabrowski Asit Dan Wolfgang Ziegler Heiko Ludwig Discussion ---------- - On updated termination diagram: * Asit to send a note on the mailing list to verify that we really have a transition from PendingAndTerminating to ObservedAndTerminating. None of us seem to be able to come up with a message sequence that would cause that to happen. * Asit will do an additional diagram to show the initial states that may be seen. - Spreadsheet row 10: Heiko to validate the schema as it relates to ServiceTermState and GuaranteeTermState. Heiko to post those changes back to the mailing list, and we'll determine follow-up steps on the next call (which is on Friday). - The next call will be on Friday, 4/7, same time of day! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.ogf.org/pipermail/graap-wg/attachments/20060407/cf62d055/attachment.html From jim_pruyne at hp.com Fri Apr 7 10:04:26 2006 From: jim_pruyne at hp.com (Jim Pruyne) Date: Fri, 07 Apr 2006 10:04:26 -0500 Subject: [graap-wg] Minutes from 4/7/06 telecon Message-ID: <44367F7A.1090801@hp.com> Minutes are attached. We will have another call at the usual Wed. time next week, and continue the extra Fri. calls at the same time until the next GGF. --- Jim -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: Apr0706-minutes.txt Url: http://www.ogf.org/pipermail/graap-wg/attachments/20060407/646ba2ee/attachment.txt From nakata at mtg.biglobe.ne.jp Fri Apr 7 10:15:26 2006 From: nakata at mtg.biglobe.ne.jp (Toshiyuki Nakata) Date: Sat, 08 Apr 2006 00:15:26 +0900 Subject: [graap-wg] minutes from 4/5 telecon In-Reply-To: References: Message-ID: <4436820E.3010901@mtg.biglobe.ne.jp> Hi Heiko: thank you very much about looking into the schema. My problem had been that in Sections 7.2 and Section 7.3 There are descriptions of pseudo schema for and but not in the actual schema. Is this OK? Best Regards Toshi Heiko Ludwig wrote: > Regarding my todo: > > I didn't get to validating the schema in time prior to the Friday call. > However, we do have the TermStateType in the schema. > > > > > > > > > > > There is no separate GuaranteeTermStateType but a > GuaranteeTermStateListType since they always come in lists in our port > types. the idea being that, on a domain level, subtypes of different name > spaces can be nested in. > > As to my understanding and as things look to me, this is ok. However, we > should verify the whole schema, anyway. > > Heiko > > > ----- > Heiko Ludwig, Dr. rer. pol. > IBM TJ Watson Research Center, PO Box 704, Yorktown, NY, 10598 > hludwig at us.ibm.com, tel. +1 914 784 7160, mob. +1 646 675 8469 > http://www.research.ibm.com/people/h/hludwig/ > > > > > > Jim Pruyne > Sent by: owner-graap-wg at ggf.org > 04/05/2006 11:12 AM > > To > GRAAP-WG > cc > > Subject > [graap-wg] minutes from 4/5 telecon > > > > > > > Are attached. Note that the next call will be on Friday, 4/7, at the > usual time of day. Reminder announcement to follow. > > --- Jim > > > Minutes from the April 5, 2006 GRAAP Telecon > > Attendees > --------- > Toshi Nakata > Jim Pruyne > Chris Dabrowski > Asit Dan > Wolfgang Ziegler > Heiko Ludwig > > Discussion > ---------- > > - On updated termination diagram: > * Asit to send a note on the mailing list to verify that we really > have a transition from PendingAndTerminating to > ObservedAndTerminating. None of us seem to be able to come up with > a message sequence that would cause that to happen. > * Asit will do an additional diagram to show the initial states that > may be seen. > > - Spreadsheet row 10: Heiko to validate the schema as it relates to > ServiceTermState and GuaranteeTermState. Heiko to post those > changes back to the mailing list, and we'll determine follow-up > steps on the next call (which is on Friday). > > - The next call will be on Friday, 4/7, same time of day! > > > From nakata at mtg.biglobe.ne.jp Fri Apr 7 10:23:12 2006 From: nakata at mtg.biglobe.ne.jp (Toshiyuki Nakata) Date: Sat, 08 Apr 2006 00:23:12 +0900 Subject: [graap-wg] minutes from 4/5 telecon In-Reply-To: <4436820E.3010901@mtg.biglobe.ne.jp> References: <4436820E.3010901@mtg.biglobe.ne.jp> Message-ID: <443683E0.8030606@mtg.biglobe.ne.jp> Sorry: I might have not been too clear. To clarify: I've no problem with the actual XML schema. I'm only worried about whether it is OK to refer to non-defined constructs namely and in the pseudo-schema. If that is what you mean by the following I 'm quite happy. >>the idea being that, on a domain level, subtypes of different >> name spaces can be nested in. best regards Toshi Toshiyuki Nakata wrote: > Hi Heiko: > thank you very much about looking into the schema. > > My problem had been that in Sections 7.2 and Section 7.3 > There are descriptions of pseudo schema for > and > > > but not in the actual schema. > Is this OK? > > Best Regards > Toshi > > Heiko Ludwig wrote: > >> Regarding my todo: >> >> I didn't get to validating the schema in time prior to the Friday >> call. However, we do have the TermStateType in the schema. >> >> >> >> >> >> >> >> >> >> >> There is no separate GuaranteeTermStateType but a >> GuaranteeTermStateListType since they always come in lists in our port >> types. the idea being that, on a domain level, subtypes of different >> name spaces can be nested in. >> >> As to my understanding and as things look to me, this is ok. However, >> we should verify the whole schema, anyway. >> >> Heiko >> >> >> ----- >> Heiko Ludwig, Dr. rer. pol. >> IBM TJ Watson Research Center, PO Box 704, Yorktown, NY, 10598 >> hludwig at us.ibm.com, tel. +1 914 784 7160, mob. +1 646 675 8469 >> http://www.research.ibm.com/people/h/hludwig/ >> >> >> >> >> >> Jim Pruyne Sent by: owner-graap-wg at ggf.org >> 04/05/2006 11:12 AM >> >> To >> GRAAP-WG >> cc >> >> Subject >> [graap-wg] minutes from 4/5 telecon >> >> >> >> >> >> >> Are attached. Note that the next call will be on Friday, 4/7, at the >> usual time of day. Reminder announcement to follow. >> >> --- Jim >> >> >> Minutes from the April 5, 2006 GRAAP Telecon >> >> Attendees >> --------- >> Toshi Nakata >> Jim Pruyne >> Chris Dabrowski >> Asit Dan >> Wolfgang Ziegler >> Heiko Ludwig >> >> Discussion >> ---------- >> >> - On updated termination diagram: >> * Asit to send a note on the mailing list to verify that we really >> have a transition from PendingAndTerminating to >> ObservedAndTerminating. None of us seem to be able to come up with >> a message sequence that would cause that to happen. >> * Asit will do an additional diagram to show the initial states that >> may be seen. >> >> - Spreadsheet row 10: Heiko to validate the schema as it relates to >> ServiceTermState and GuaranteeTermState. Heiko to post those >> changes back to the mailing list, and we'll determine follow-up >> steps on the next call (which is on Friday). >> >> - The next call will be on Friday, 4/7, same time of day! >> >> >> > > > From hludwig at us.ibm.com Fri Apr 7 15:24:36 2006 From: hludwig at us.ibm.com (Heiko Ludwig) Date: Fri, 7 Apr 2006 16:24:36 -0400 Subject: [graap-wg] minutes from 4/5 telecon In-Reply-To: <443683E0.8030606@mtg.biglobe.ne.jp> Message-ID: Toshi, there are Elements (contained in the list types) with these respective names. No types, though. Hence, I think describing the element it ok. Heiko ----- Heiko Ludwig, Dr. rer. pol. IBM TJ Watson Research Center, PO Box 704, Yorktown, NY, 10598 hludwig at us.ibm.com, tel. +1 914 784 7160, mob. +1 646 675 8469 http://www.research.ibm.com/people/h/hludwig/ Toshiyuki Nakata 04/07/2006 11:23 AM Please respond to t-nakata at cw.jp.nec.com To t-nakata at cw.jp.nec.com cc Heiko Ludwig/Watson/IBM at IBMUS, Jim Pruyne , GRAAP-WG , owner-graap-wg at ggf.org Subject Re: [graap-wg] minutes from 4/5 telecon Sorry: I might have not been too clear. To clarify: I've no problem with the actual XML schema. I'm only worried about whether it is OK to refer to non-defined constructs namely and in the pseudo-schema. If that is what you mean by the following I 'm quite happy. >>the idea being that, on a domain level, subtypes of different >> name spaces can be nested in. best regards Toshi Toshiyuki Nakata wrote: > Hi Heiko: > thank you very much about looking into the schema. > > My problem had been that in Sections 7.2 and Section 7.3 > There are descriptions of pseudo schema for > and > > > but not in the actual schema. > Is this OK? > > Best Regards > Toshi > > Heiko Ludwig wrote: > >> Regarding my todo: >> >> I didn't get to validating the schema in time prior to the Friday >> call. However, we do have the TermStateType in the schema. >> >> >> >> >> >> >> >> >> >> >> There is no separate GuaranteeTermStateType but a >> GuaranteeTermStateListType since they always come in lists in our port >> types. the idea being that, on a domain level, subtypes of different >> name spaces can be nested in. >> >> As to my understanding and as things look to me, this is ok. However, >> we should verify the whole schema, anyway. >> >> Heiko >> >> >> ----- >> Heiko Ludwig, Dr. rer. pol. >> IBM TJ Watson Research Center, PO Box 704, Yorktown, NY, 10598 >> hludwig at us.ibm.com, tel. +1 914 784 7160, mob. +1 646 675 8469 >> http://www.research.ibm.com/people/h/hludwig/ >> >> >> >> >> >> Jim Pruyne Sent by: owner-graap-wg at ggf.org >> 04/05/2006 11:12 AM >> >> To >> GRAAP-WG >> cc >> >> Subject >> [graap-wg] minutes from 4/5 telecon >> >> >> >> >> >> >> Are attached. Note that the next call will be on Friday, 4/7, at the >> usual time of day. Reminder announcement to follow. >> >> --- Jim >> >> >> Minutes from the April 5, 2006 GRAAP Telecon >> >> Attendees >> --------- >> Toshi Nakata >> Jim Pruyne >> Chris Dabrowski >> Asit Dan >> Wolfgang Ziegler >> Heiko Ludwig >> >> Discussion >> ---------- >> >> - On updated termination diagram: >> * Asit to send a note on the mailing list to verify that we really >> have a transition from PendingAndTerminating to >> ObservedAndTerminating. None of us seem to be able to come up with >> a message sequence that would cause that to happen. >> * Asit will do an additional diagram to show the initial states that >> may be seen. >> >> - Spreadsheet row 10: Heiko to validate the schema as it relates to >> ServiceTermState and GuaranteeTermState. Heiko to post those >> changes back to the mailing list, and we'll determine follow-up >> steps on the next call (which is on Friday). >> >> - The next call will be on Friday, 4/7, same time of day! >> >> >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.ogf.org/pipermail/graap-wg/attachments/20060407/e2f54736/attachment.html From t-nakata at cw.jp.nec.com Sun Apr 9 23:24:18 2006 From: t-nakata at cw.jp.nec.com (Toshiyuki Nakata) Date: Mon, 10 Apr 2006 13:24:18 +0900 Subject: [graap-wg] minutes from 4/5 telecon In-Reply-To: Message-ID: <000701c65c56$a27c0f20$ab84380a@ISIBASI> Heiko: Thank you very much for checking, Just to make sure. How about expressions like, /wsag:ServiceTermState This element contains the state of a service term, one of the following top-level elements: in P.37 or expressions like: /wsag:ServiceTermState/wsag:NotReady in P.37 compared to /wsag:ServiceTermStateList/wsag:NotReady in P.49? Best Regards Toshi ----- Toshiyuki Nakata ?????? Executive Chief Engineer, Central Research Lab. NEC 1753, Shimonumabe, Nakahara-Ku, Kawasaki,Kanagawa 211-8666,Japan Tel +81-44-431-7653 (NEC Internal 22-60035) Fax +81-44-431-7609 (NEC Internal 22-60509) > -----Original Message----- > From: Heiko Ludwig [mailto:hludwig at us.ibm.com] > Sent: Saturday, April 08, 2006 5:25 AM > To: t-nakata at cw.jp.nec.com > Cc: GRAAP-WG; Jim Pruyne; owner-graap-wg at ggf.org; > t-nakata at cw.jp.nec.com > Subject: Re: [graap-wg] minutes from 4/5 telecon > > > Toshi, > > there are Elements (contained in the list types) with these > respective names. No types, though. Hence, I think describing > the element it ok. > > Heiko > > ----- > Heiko Ludwig, Dr. rer. pol. > IBM TJ Watson Research Center, PO Box 704, Yorktown, NY, > 10598 hludwig at us.ibm.com, tel. +1 914 784 7160, mob. +1 646 > 675 8469 http://www.research.ibm.com/people/h/hludwig/ > > > > > > Toshiyuki Nakata > > 04/07/2006 11:23 AM > Please respond to > t-nakata at cw.jp.nec.com > > To > t-nakata at cw.jp.nec.com > cc > Heiko Ludwig/Watson/IBM at IBMUS, Jim Pruyne > , GRAAP-WG , > owner-graap-wg at ggf.org Subject > Re: [graap-wg] minutes from 4/5 telecon > > > > > > > Sorry: I might have not been too clear. > To clarify: > I've no problem with the actual XML schema. > I'm only worried about whether it is OK to refer to non-defined > constructs namely and > > in the pseudo-schema. > > If that is what you mean by the following I 'm quite happy. > >>the idea being that, on a domain level, subtypes of different > >> name spaces can be nested in. > > > best regards > Toshi > > Toshiyuki Nakata wrote: > > > Hi Heiko: > > thank you very much about looking into the schema. > > > > My problem had been that in Sections 7.2 and Section 7.3 > > There are descriptions of pseudo schema for > > and > > > > > > but not in the actual schema. > > Is this OK? > > > > Best Regards > > Toshi > > > > Heiko Ludwig wrote: > > > >> Regarding my todo: > >> > >> I didn't get to validating the schema in time prior to the Friday > >> call. However, we do have the TermStateType in the schema. > >> > >> > >> > >> processContents="lax"/> > >> > >> type="wsag:InnerTermStateType"/> > >> > >> > >> > >> > >> There is no separate GuaranteeTermStateType but a > >> GuaranteeTermStateListType since they always come in lists > in our port > >> types. the idea being that, on a domain level, subtypes of > different > >> name spaces can be nested in. > >> > >> As to my understanding and as things look to me, this is > ok. However, > >> we should verify the whole schema, anyway. > >> > >> Heiko > >> > >> > >> ----- > >> Heiko Ludwig, Dr. rer. pol. > >> IBM TJ Watson Research Center, PO Box 704, Yorktown, NY, 10598 > >> hludwig at us.ibm.com, tel. +1 914 784 7160, mob. +1 646 675 8469 > >> http://www.research.ibm.com/people/h/hludwig/ > >> > >> > >> > >> > >> > >> Jim Pruyne Sent by: owner-graap-wg at ggf.org > >> 04/05/2006 11:12 AM > >> > >> To > >> GRAAP-WG > >> cc > >> > >> Subject > >> [graap-wg] minutes from 4/5 telecon > >> > >> > >> > >> > >> > >> > >> Are attached. Note that the next call will be on Friday, > 4/7, at the > >> usual time of day. Reminder announcement to follow. > >> > >> --- Jim > >> > >> > >> Minutes from the April 5, 2006 GRAAP Telecon > >> > >> Attendees > >> --------- > >> Toshi Nakata > >> Jim Pruyne > >> Chris Dabrowski > >> Asit Dan > >> Wolfgang Ziegler > >> Heiko Ludwig > >> > >> Discussion > >> ---------- > >> > >> - On updated termination diagram: > >> * Asit to send a note on the mailing list to verify that > we really > >> have a transition from PendingAndTerminating to > >> ObservedAndTerminating. None of us seem to be able to > come up with > >> a message sequence that would cause that to happen. > >> * Asit will do an additional diagram to show the initial > states that > >> may be seen. > >> > >> - Spreadsheet row 10: Heiko to validate the schema as it relates to > >> ServiceTermState and GuaranteeTermState. Heiko to post those > >> changes back to the mailing list, and we'll determine follow-up > >> steps on the next call (which is on Friday). > >> > >> - The next call will be on Friday, 4/7, same time of day! > >> > >> > >> > > > > > > > > > > From jim_pruyne at hp.com Tue Apr 11 22:44:16 2006 From: jim_pruyne at hp.com (Jim Pruyne) Date: Tue, 11 Apr 2006 22:44:16 -0500 Subject: [graap-wg] telecon on 4/12 Message-ID: <443C7790.9010102@hp.com> We will have a telecon. on Wed. morning/evening. Dial-in numbers will be the same: 9:00AM Central Daylight Time US (UTC-5) which should be: 10:00AM Eastern Daylight Time US 1500 UK 1600 Germany 2300 Japan 2100 Thailand Phone Number: 866-673-8466 in the US. 702-477-6031 for those outside the US. Conference code #8578310. From t-nakata at cw.jp.nec.com Tue Apr 11 22:57:30 2006 From: t-nakata at cw.jp.nec.com (Toshiyuki Nakata) Date: Wed, 12 Apr 2006 12:57:30 +0900 Subject: [graap-wg] telecon on 4/12 In-Reply-To: <443C7790.9010102@hp.com> Message-ID: <002801c65de5$38d69a00$ab84380a@ISIBASI> I had forgotten to update the comment-list. Please find attached. best regards Toshi ----- Toshiyuki Nakata ?????? Executive Chief Engineer, Central Research Lab. NEC 1753, Shimonumabe, Nakahara-Ku, Kawasaki,Kanagawa 211-8666,Japan Tel +81-44-431-7653 (NEC Internal 22-60035) Fax +81-44-431-7609 (NEC Internal 22-60509) > -----Original Message----- > From: owner-graap-wg at ggf.org [mailto:owner-graap-wg at ggf.org] > On Behalf Of Jim Pruyne > Sent: Wednesday, April 12, 2006 12:44 PM > To: GRAAP-WG > Subject: [graap-wg] telecon on 4/12 > > We will have a telecon. on Wed. morning/evening. Dial-in > numbers will be the same: > 9:00AM Central Daylight Time US (UTC-5) > which should be: > 10:00AM Eastern Daylight Time US > 1500 UK > 1600 Germany > 2300 Japan > 2100 Thailand > > Phone Number: 866-673-8466 in the US. 702-477-6031 for those > outside the US. > Conference code #8578310. > -------------- next part -------------- A non-text attachment was scrubbed... Name: PublicComments060407.xls Type: application/vnd.ms-excel Size: 114688 bytes Desc: not available Url : http://www.ogf.org/pipermail/graap-wg/attachments/20060412/1db58642/attachment.xls From jim_pruyne at hp.com Wed Apr 12 10:14:23 2006 From: jim_pruyne at hp.com (Jim Pruyne) Date: Wed, 12 Apr 2006 10:14:23 -0500 Subject: [graap-wg] minutes from 4/12 telecon Message-ID: <443D194F.7080909@hp.com> Are attached. We'll meet again on this Friday for an extra session trying to complete the spec before the next GGF. --- Jim -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: Apr1206-minutes.txt Url: http://www.ogf.org/pipermail/graap-wg/attachments/20060412/961a4af2/attachment.txt From nakata at mtg.biglobe.ne.jp Wed Apr 12 10:23:48 2006 From: nakata at mtg.biglobe.ne.jp (Toshiyuki Nakata) Date: Thu, 13 Apr 2006 00:23:48 +0900 Subject: [graap-wg] minutes from 4/12 telecon In-Reply-To: <443D194F.7080909@hp.com> References: <443D194F.7080909@hp.com> Message-ID: <443D1B84.10000@mtg.biglobe.ne.jp> Public Comments Sheet attached. Best Regards Toshi Jim Pruyne wrote: > Are attached. We'll meet again on this Friday for an extra session > trying to complete the spec before the next GGF. > > --- Jim > > -------------- next part -------------- A non-text attachment was scrubbed... Name: PublicComments060412.xls Type: application/vnd.ms-excel Size: 109568 bytes Desc: not available Url : http://www.ogf.org/pipermail/graap-wg/attachments/20060413/68898234/attachment.xls From jim_pruyne at hp.com Fri Apr 14 01:59:26 2006 From: jim_pruyne at hp.com (Jim Pruyne) Date: Fri, 14 Apr 2006 01:59:26 -0500 Subject: [graap-wg] extra telecon on 4/14 Message-ID: <443F484E.8080506@hp.com> We will have a telecon. on FRI. morning/evening. Dial-in numbers will be the same. The time in the US will remain the same, but the US has changed to daylight savings time over the weekend. I believe this gives us the times: 9:00AM Central Daylight Time US (UTC-5) which should be: 10:00AM Eastern Daylight Time US 1500 UK 1600 Germany 2300 Japan 2100 Thailand Phone Number: 866-673-8466 in the US. 702-477-6031 for those outside the US. Conference code #8578310. --- Jim From jim_pruyne at hp.com Fri Apr 14 10:08:22 2006 From: jim_pruyne at hp.com (Jim Pruyne) Date: Fri, 14 Apr 2006 10:08:22 -0500 Subject: [graap-wg] minutes from 4/14 telecon Message-ID: <443FBAE6.3060005@hp.com> They are attached. --- Jim -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: Apr1406-minutes.txt Url: http://www.ogf.org/pipermail/graap-wg/attachments/20060414/b57870b6/attachment.txt From nakata at mtg.biglobe.ne.jp Fri Apr 14 10:21:00 2006 From: nakata at mtg.biglobe.ne.jp (Toshiyuki Nakata) Date: Sat, 15 Apr 2006 00:21:00 +0900 Subject: [graap-wg] minutes from 4/14 telecon In-Reply-To: <443FBAE6.3060005@hp.com> References: <443FBAE6.3060005@hp.com> Message-ID: <443FBDDC.3080003@mtg.biglobe.ne.jp> And the Comments list attached. I'll probably move the 'Done' ones to the Done Page when I've cross checked the doc in Gridforge. Best Regards & Happy Easter! Toshi Jim Pruyne wrote: > They are attached. > > --- Jim > > -------------- next part -------------- A non-text attachment was scrubbed... Name: PublicComments060415.xls Type: application/vnd.ms-excel Size: 111616 bytes Desc: not available Url : http://www.ogf.org/pipermail/graap-wg/attachments/20060415/3e7eba34/attachment.xls From jim_pruyne at hp.com Fri Apr 14 12:22:22 2006 From: jim_pruyne at hp.com (Jim Pruyne) Date: Fri, 14 Apr 2006 12:22:22 -0500 Subject: [graap-wg] minutes from 4/14 telecon In-Reply-To: References: Message-ID: <443FDA4E.2020706@hp.com> Heiko Ludwig wrote: > > > > > > - Spreadsheet row 23: Heiko will look into adding some text to clarify > > that when there are no service terms, there can also be no guarantee > > terms since the guarantee term must refer to a service term. > > > > Since this text is a general introduction, not a definition related > immediately to the schema, I propose this wording, which takes into > account that there might be alternative term types, replacing the > current sentence quoted in the spreadsheet. > > An agreement includes information on the agreement parties and a set > of terms. The terms MAY comprise one or more service terms and zero or > more guarantee terms specifying service level objectives and business > values associated with these objectives. > > Heiko This looks good to me. --- Jim From hludwig at us.ibm.com Fri Apr 14 11:53:00 2006 From: hludwig at us.ibm.com (Heiko Ludwig) Date: Fri, 14 Apr 2006 12:53:00 -0400 Subject: [graap-wg] minutes from 4/14 telecon In-Reply-To: <443FBAE6.3060005@hp.com> Message-ID: > > - Spreadsheet row 23: Heiko will look into adding some text to clarify > that when there are no service terms, there can also be no guarantee > terms since the guarantee term must refer to a service term. > Since this text is a general introduction, not a definition related immediately to the schema, I propose this wording, which takes into account that there might be alternative term types, replacing the current sentence quoted in the spreadsheet. An agreement includes information on the agreement parties and a set of terms. The terms MAY comprise one or more service terms and zero or more guarantee terms specifying service level objectives and business values associated with these objectives. Heiko -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.ogf.org/pipermail/graap-wg/attachments/20060414/da09755a/attachment.html From jim_pruyne at hp.com Wed Apr 19 01:07:43 2006 From: jim_pruyne at hp.com (Jim Pruyne) Date: Wed, 19 Apr 2006 01:07:43 -0500 Subject: [graap-wg] telecon on 4/19 Message-ID: <4445D3AF.4030909@hp.com> We will have a telecon. on Wed. morning/evening. Dial-in numbers will be the same: 9:00AM Central Daylight Time US (UTC-5) which should be: 10:00AM Eastern Daylight Time US 1500 UK 1600 Germany 2300 Japan 2100 Thailand Phone Number: 866-673-8466 in the US. 702-477-6031 for those outside the US. Conference code #8578310. From parkinm at cs.man.ac.uk Thu Apr 20 06:58:58 2006 From: parkinm at cs.man.ac.uk (Michael Parkin) Date: Thu, 20 Apr 2006 12:58:58 +0100 Subject: [graap-wg] Access to "Definition of Advance Reservation" Document Message-ID: Hi, I'm trying to access the link for 'the definition of advance reservation' [1] from the GRAAP-WG GridForge project summary. When I try to do so, I get the following error: "DCMN-000073: The requested document Advance-Reservation-Definition- htm resides in a hidden category. Permission denied". Is this definition publicly available, or a configuration error on the website? Thanks, Michael. [1] https://forge.gridforum.org/projects/graap-wg/document/Advance- Reservation-Definition-htm/en/1/Advance-Reservation-Definition-htm.html From ph.wieder at fz-juelich.de Thu Apr 20 07:14:56 2006 From: ph.wieder at fz-juelich.de (Philipp Wieder) Date: Thu, 20 Apr 2006 14:14:56 +0200 Subject: [graap-wg] Access to "Definition of Advance Reservation" Document In-Reply-To: References: Message-ID: <44477B40.9080803@fz-juelich.de> Dear Michael, the definition should be publicly available. Seems to me that it was until now only visible if you have logged in, but I changed that. Best regards, Philipp. Michael Parkin wrote: > Hi, > > I'm trying to access the link for 'the definition of advance > reservation' [1] from the GRAAP-WG GridForge project summary. > > When I try to do so, I get the following error: > > "DCMN-000073: The requested document Advance-Reservation-Definition-htm > resides in a hidden category. Permission denied". > > Is this definition publicly available, or a configuration error on the > website? > > Thanks, > > Michael. > > [1] > https://forge.gridforum.org/projects/graap-wg/document/Advance-Reservation-Definition-htm/en/1/Advance-Reservation-Definition-htm.html > > From jim_pruyne at hp.com Fri Apr 21 09:00:22 2006 From: jim_pruyne at hp.com (Jim Pruyne) Date: Fri, 21 Apr 2006 09:00:22 -0500 Subject: [graap-wg] no telecon today Message-ID: <4448E576.9010604@hp.com> I have a conflict, so there's no telecon today. Sorry for the very late, non-reminder. We're looking to have one on Mon. or Tues. of next week. If people could let me know their availability on those days, I'll use that to choose which day to have it. Thanks. --- Jim From maclaren at cct.lsu.edu Mon Apr 24 01:33:23 2006 From: maclaren at cct.lsu.edu (Jon MacLaren) Date: Mon, 24 Apr 2006 01:33:23 -0500 Subject: [graap-wg] GRAAP use case doc in public comment In-Reply-To: <05E4BD34-F2A9-4460-9222-0EFF006F95B3@cct.lsu.edu> References: <05E4BD34-F2A9-4460-9222-0EFF006F95B3@cct.lsu.edu> Message-ID: <5BE10987-E65A-4FC2-8BD7-CE2D6C8B81A1@cct.lsu.edu> All, The GRAAP-WG informational use case document is now in public comment. As discussed at the GGF in Boston, it'd be great to see this document finished off. To make (or view) comments, please visit: https://forge.gridforum.org/forum/forum.php?forum_id=609 The PDF is at: http://www.ggf.org/Public_Comment_Docs/Documents/Apr-2006/draft-ggf- graap-usagescenarios-03.pdf As this is an informational document, you only have 30 days (starting April 22nd, I assume). It'd be great if all the active people in the group could give this one last once-over. Cheers, Jon. From jim_pruyne at hp.com Mon Apr 24 02:16:49 2006 From: jim_pruyne at hp.com (Jim Pruyne) Date: Mon, 24 Apr 2006 02:16:49 -0500 Subject: [graap-wg] telecon on 4/24 Message-ID: <444C7B61.3020301@hp.com> All, To try to make up for the fact that I will be unavailable for any telecons the remainder of this week, it seems that the best time to try to have one is Monday. Times and numbers will be the same as usual: 9:00AM Central Daylight Time US (UTC-5) which should be: 10:00AM Eastern Daylight Time US 1500 UK 1600 Germany 2300 Japan 2100 Thailand Phone Number: 866-673-8466 in the US. 702-477-6031 for those outside the US. Conference code #8578310. --- Jim From jim_pruyne at hp.com Mon Apr 24 10:31:56 2006 From: jim_pruyne at hp.com (Jim Pruyne) Date: Mon, 24 Apr 2006 10:31:56 -0500 Subject: [graap-wg] minutes from 4/24 telecon Message-ID: <444CEF6C.9010808@hp.com> Minutes are attached. The next telecon will be held on May 3, at the usual Wed. time. At this time, we intend to survey the state of the document, and determine any steps needed to submit back to GGF. --- Jim -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: Apr2406-minutes.txt Url: http://www.ogf.org/pipermail/graap-wg/attachments/20060424/426bd4b0/attachment.txt From nakata at mtg.biglobe.ne.jp Mon Apr 24 10:42:26 2006 From: nakata at mtg.biglobe.ne.jp (nakata) Date: Tue, 25 Apr 2006 00:42:26 +0900 Subject: [graap-wg] minutes from 4/24 telecon In-Reply-To: <444CEF6C.9010808@hp.com> References: <444CEF6C.9010808@hp.com> Message-ID: <444CF1E2.1070907@mtg.biglobe.ne.jp> Comments List attached. Best Regards Toshi Jim Pruyne wrote: > Minutes are attached. The next telecon will be held on May 3, at the > usual Wed. time. At this time, we intend to survey the state of the > document, and determine any steps needed to submit back to GGF. > > --- Jim > > -------------- next part -------------- A non-text attachment was scrubbed... Name: PublicComments060424.xls Type: application/vnd.ms-excel Size: 112640 bytes Desc: not available Url : http://www.ogf.org/pipermail/graap-wg/attachments/20060425/2e2ed3b0/attachment.xls From hludwig at us.ibm.com Mon Apr 24 12:35:24 2006 From: hludwig at us.ibm.com (Heiko Ludwig) Date: Mon, 24 Apr 2006 13:35:24 -0400 Subject: [graap-wg] minutes from 4/24 telecon In-Reply-To: <444CEF6C.9010808@hp.com> Message-ID: The ContinuingFaultType is the specific WS-Agreement fault that we defined. I don't know anymore the rationale why it was called that name, but we might want to have a sepate fault type. Karl, do you rember the semantics of this name? Heiko ----- Heiko Ludwig, Dr. rer. pol. IBM TJ Watson Research Center, PO Box 704, Yorktown, NY, 10598 hludwig at us.ibm.com, tel. +1 914 784 7160, mob. +1 646 675 8469 http://www.research.ibm.com/people/h/hludwig/ Jim Pruyne Sent by: owner-graap-wg at ggf.org 04/24/2006 11:31 AM To GRAAP-WG cc Subject [graap-wg] minutes from 4/24 telecon Minutes are attached. The next telecon will be held on May 3, at the usual Wed. time. At this time, we intend to survey the state of the document, and determine any steps needed to submit back to GGF. --- Jim Minutes from the April 24, 2006 GRAAP Telecon Attendees --------- Toshi Nakata Jim Pruyne Chris Dabrowski Asit Dan Discussion ---------- - Spreadsheet row 41: We'd like Heiko to respond about whether there's still a need for the ContinuingFaultType, if not, we'd like to delete. - Jim to run the schema as defined in the document through the Axis tool chain to verify the correctness. - Jim to make sure that all of the comments in the comment tracker have appropriate responses. - Spreadsheet row 37: We agreed that even if accept fails, the agreement is still accepted, and the initiator must query to find out the status. It would be up to the responder to use other mechanisms like signing or reliable delivery if they do not want to risk accepting an agreement that comes from an invalid source. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.ogf.org/pipermail/graap-wg/attachments/20060424/8d6dbb3b/attachment.html From karlcz at univa.com Mon Apr 24 21:28:45 2006 From: karlcz at univa.com (Karl Czajkowski) Date: Tue, 25 Apr 2006 09:28:45 +0700 Subject: [graap-wg] minutes from 4/24 telecon In-Reply-To: References: <444CEF6C.9010808@hp.com> Message-ID: <20060425022845.GE25317@moraine.localdomain> On Apr 24, Heiko Ludwig modulated: > > The ContinuingFaultType is the specific WS-Agreement fault that we > defined. I don't know anymore the rationale why it was called that > name, but we might want to have a sepate fault type. > > Karl, do you rember the semantics of this name? > > Heiko > Yes, I think it is obsolete. It had to do with distinguishing continuing or terminal faults in negotiations, i.e. continuing fault is like an E_BUSY etc, temorary failure which cancels an operation while terminal fault would be like a permanent fault on the negotiation (web resource) meaning the resource is no longer useful. I think this is much less important with the current offer/accept handshake, i.e. there is no ongoing conversation of counter-offers that you might or might not want to terminate. For Agreement resources, I think we can leave it up to the individual fault types to define their semantics, and not bother with this. For example, it is going to be underlying WS-Addressing faults that indicate your agreement resource EPR is invalid, right? We don't even specify the important faults. karl -- Karl Czajkowski karlcz at univa.com