RE: [graap-wg] url for the Web Services Policy WG in W3C
Hello: Asit: Thank you very much for the pointer.
I intend to attend today's teleconference, but I might fail to do so, .. All in all I would suggest that for this version of the spec, we should stick to the current spec to be released and consider the modifications for the next version of the specification.
Sorry I couldn't attend last week's teleconference. Afterwards I heard that the modification to the current spec would be small.... So.. Since the change seems to be small, could we keep the spec as it is and reflect the change when the new WS-Policy specification is finalised ? 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: Toshiyuki Nakata [mailto:t-nakata@cw.jp.nec.com] Sent: Wednesday, June 14, 2006 9:18 AM To: 'Asit Dan' Cc: 'GRAAP-WG' Subject: RE: [graap-wg] url for the Web Services Policy WG in W3C
Hello: Asit: Thank you very much for the pointer.
I intend to attend today's teleconference, but I might fail to do so, so here are my views on PROS and CONS:
PROS: Quote: from http://www.w3.org/2006/04/ws-policy-charter.html "Web Services Policy defines a flexible policy data model and an extensible grammar for expressing the capabilities, requirements and general characteristics of a Web service, and defines mechanisms for associating policies with Web service constructs. Web Services Policy is used to convey the conditions for an interaction between a Web service requester and a Web service provider." It would be good to have this related part in WS-Agreement described in a compatible way as that would make acceptance of WS-Agreement easier.
CONS: 1)Adopting WS-Policy would mean that WS-Agreement would depend on a specification which still needs to be agreeed to. While the charter does say that "Therefore, this Working Group shall be schedule-driven and Web Services Policy shall remain compatible with and to the extent possible accommodate the use of these existing policy assertions. " Until the final draft is out, one may not know what will stay stable. The end date is 31 December 2007 which is a year and a half away. I think many people have been waiting for WS-Agreement spec to be completed and to have to really wait more might have negative effects.
2)Adopting WS-Policy would mean that there would be need to change the current implementations. I do not know how many implementations of WS-policy there are in the world but to have to modify the current imlplementation would have some negative issues (at least for the implementation people) for getting interoperability etc.
3)(This is a minor issue) Since this has a large impact, we might need another call of public comments.
All in all I would suggest that for this version of the spec, we should stick to the current spec to be released and consider the modifications for the next version of the specification.
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@ggf.org [mailto:owner-graap-wg@ggf.org] On Behalf Of Asit Dan Sent: Thursday, June 08, 2006 12:04 AM To: Toshiyuki Nakata Cc: GRAAP-WG Subject: [graap-wg] url for the Web Services Policy WG in W3C
Toshi, As per the discussion in today's call, here is the url for the Web Services Policy Working Group Charter. http://www.w3.org/2006/04/ws-policy-charter.html
You can find the WS-Policy document by following the WS-Policy” Member Submission <http://www.w3.org/Submission/2006/06/> link. Regards. Asit Dan, Ph.D. SWG SOA Design Requirements Phone: (914) 766-1767 Internet: asit@us.ibm.com ICSOC 06 PC Chair (http://www.icsoc.org)
Hi, I am curious what is the state of this discussion. I've read Toshi's previous email on pros/cons and I agree with him. I think at this point (one step before publication of the WS-Agreement spec) making a change that brings back a dependency on a specification that is about to enter the standardization process is not a good idea. -- Andreas Savva Toshiyuki Nakata wrote:
Hello: Asit: Thank you very much for the pointer.
I intend to attend today's teleconference, but I might fail to do so, .. All in all I would suggest that for this version of the spec, we should stick to the current spec to be released and consider the modifications for the next version of the specification.
Sorry I couldn't attend last week's teleconference.
Afterwards I heard that the modification to the current spec would be small....
So.. Since the change seems to be small, could we keep the spec as it is and reflect the change when the new WS-Policy specification is finalised ?
Best Regards Toshi
-----
-- Andreas Savva Fujitsu Laboratories Ltd
I agree. It doesn't seem to add much to WS-Agreement at this point, and I think people who want to engage in an "SLA and policy" discussion should be able to observe the trivial mapping necessary to understand our compositions as policy composition. karl On Jun 28, Andreas Savva modulated: ...
I've read Toshi's previous email on pros/cons and I agree with him. I think at this point (one step before publication of the WS-Agreement spec) making a change that brings back a dependency on a specification that is about to enter the standardization process is not a good idea.
-- Andreas Savva
-- Karl Czajkowski karlcz@univa.com
Andreas, We didn't have a discussion on this in our weekly call. As Karl and Toshi noted that this is a trivial change (and Heiko provided a validated schema with this change), so from a pure technical implementation viewpoint this doesn't impact the spec even at this late stage. I believe this is a very important issue, and we should have a well reasoned and well articulated position on this for the wider audience -- whatever may be the final decision of the group. The issue will keep coming up as the wider audience (Web Services community) will fail to grasp the strong objections of this group to aligning this spec to WS* stack, and WS-Policy in particular. I believe the goal of this group is to make WS-Agreement specification to be adopted by the wider Web Services community, and not to be perceived as something niche for job scheduling or just "Grid-thingy". Off course, in the same spirit, I (we) have equally strongly advocated to the JSDL community for leveraging this spec in specifying flexible scheduling objectives. There are several benefits from this change: better alignment and acceptance by the broader WS* community and also avoiding confusion on SLA vs Policy. A wide spectrum of folks I hear from in my everyday activities (architects, developers, customers, analysts...) don't quite distinguish SLA and Policy. [ Off course, that's not my position.] Typical comments I hear -- are you using WS-Policy in specifying service level assertions? By embracing the use of WS-Policy as an envelope for agreement terms we not only avoid this confusion but also easily demonstrate what additional aspects are being covered by WS-Ag spec. Finally, in the runtime enforcement environments (service registry, monitoring system, workload manager, ... ) SLA derived enforcement policies can be represented uniformly. Given that WS-Policy draft (that has been submitted to W3C) is very stable - has been co-authored by representatives from several organizations, already implemented by many vendors and many other OASIS standards on security, transaction, reliability, etc. dependent on this spec - and changes to the current draft of WS-Ag spec is minimal (not surprising, since we started with WS-Policy for term composition), there are many good reasons to embrace WS-Policy now. In any case, it's a public document (W3C), and we can make WS-Ag spec dependent only on the submitted draft. Regards. Asit Dan, Ph.D. SWG SOA Design Requirements Phone: (914) 766-1767 Internet: asit@us.ibm.com ICSOC 06 PC Chair (http://www.icsoc.org) Karl Czajkowski <karlcz@univa.com> Sent by: owner-graap-wg@ggf.org 06/28/2006 03:20 AM To Andreas Savva <andreas.savva@jp.fujitsu.com> cc "'GRAAP-WG'" <graap-wg@gridforum.org>, Toshiyuki Nakata <t-nakata@cw.jp.nec.com>, Asit Dan/Watson/IBM@IBMUS Subject Re: [graap-wg] url for the Web Services Policy WG in W3C I agree. It doesn't seem to add much to WS-Agreement at this point, and I think people who want to engage in an "SLA and policy" discussion should be able to observe the trivial mapping necessary to understand our compositions as policy composition. karl On Jun 28, Andreas Savva modulated: ...
I've read Toshi's previous email on pros/cons and I agree with him. I think at this point (one step before publication of the WS-Agreement spec) making a change that brings back a dependency on a specification that is about to enter the standardization process is not a good idea.
-- Andreas Savva
-- Karl Czajkowski karlcz@univa.com
Hi: Apologies again for not making it on this call.. Any other moves on the pending issues? Best Regards Toshi
Andreas, We didn't have a discussion on this in our weekly call. As Karl and Toshi noted that this is a trivial change (and Heiko provided a validated schema with this change), so from a pure technical implementation viewpoint this doesn't impact the spec even at this late stage.
I believe this is a very important issue, and we should have a well reasoned and well articulated position on this for the wider audience -- whatever may be the final decision of the group. The issue will keep coming up as the wider audience (Web Services community) will fail to grasp the strong objections of this group to aligning this spec to WS* stack, and WS-Policy in particular. I believe the goal of this group is to make WS-Agreement specification to be adopted by the wider Web Services community, and not to be perceived as something niche for job scheduling or just "Grid-thingy". Off course, in the same spirit, I (we) have equally strongly advocated to the JSDL community for leveraging this spec in specifying flexible scheduling objectives.
There are several benefits from this change: better alignment and acceptance by the broader WS* community and also avoiding confusion on SLA vs Policy. A wide spectrum of folks I hear from in my everyday activities (architects, developers, customers, analysts...) don't quite distinguish SLA and Policy. [ Off course, that's not my position.] Typical comments I hear -- are you using WS-Policy in specifying service level assertions? By embracing the use of WS-Policy as an envelope for agreement terms we not only avoid this confusion but also easily demonstrate what additional aspects are being covered by WS-Ag spec. Finally, in the runtime enforcement environments (service registry, monitoring system, workload manager, ... ) SLA derived enforcement policies can be represented uniformly.
Given that WS-Policy draft (that has been submitted to W3C) is very stable - has been co-authored by representatives from several organizations, already implemented by many vendors and many other OASIS standards on security, transaction, reliability, etc. dependent on this spec - and changes to the current draft of WS-Ag spec is minimal (not surprising, since we started with WS-Policy for term composition), there are many good reasons to embrace WS-Policy now. In any case, it's a public document (W3C), and we can make WS-Ag spec dependent only on the submitted draft.
Regards. Asit Dan, Ph.D. SWG SOA Design Requirements Phone: (914) 766-1767 Internet: asit@us.ibm.com ICSOC 06 PC Chair (http://www.icsoc.org)
Karl Czajkowski <karlcz@univa.com> Sent by: owner-graap-wg@ggf.org 06/28/2006 03:20 AM
To Andreas Savva <andreas.savva@jp.fujitsu.com> cc "'GRAAP-WG'" <graap-wg@gridforum.org>, Toshiyuki Nakata <t-nakata@cw.jp.nec.com>, Asit Dan/Watson/IBM@IBMUS Subject Re: [graap-wg] url for the Web Services Policy WG in W3C
I agree. It doesn't seem to add much to WS-Agreement at this point, and I think people who want to engage in an "SLA and policy" discussion should be able to observe the trivial mapping necessary to understand our compositions as policy composition.
karl
On Jun 28, Andreas Savva modulated: ...
I've read Toshi's previous email on pros/cons and I agree with him. I think at this point (one step before publication of the WS-Agreement spec) making a change that brings back a dependency on a specification that is about to enter the standardization process is not a good idea.
-- Andreas Savva
-- Karl Czajkowski karlcz@univa.com
------- NEC 中央研究所 主席技術主幹 中田 登志之 Toshiyuki Nakata Executive Chief Engineer Central Research Laboratories NEC Corporation +81-44-431-7653
Hi Asit and everyone: Sorry: I am still a bit groggy. (Caught a cold..)
Hi: Apologies again for not making it on this call..
Asit: Thank you very much for your clarification of your opinion.
I believe this is a very important issue, and we should have a well reasoned and well articulated position on this for the wider audience -- whatever may be the final decision of the group.
I agree and still, I think at this point making changes to the spec could be dangerous due to the pros and cons I mentioned before.
Given that WS-Policy draft (that has been submitted to W3C) is very stable - has been co-authored by representatives from several organizations, already implemented by many vendors and many other OASIS standards on security, transaction, reliability, etc. dependent on this spec - and changes to the current draft of WS-Ag spec is minimal (not surprising, since we started with WS-Policy for term composition), there are many good reasons to embrace WS-Policy now.
I personally would like to see how / whether the spec would change in the new W3C community. I still think that it is too early to tell. Best regards Toshi ------- NEC 中央研究所 主席技術主幹 中田 登志之 Toshiyuki Nakata Executive Chief Engineer Central Research Laboratories NEC Corporation +81-44-431-7653
Asit, Thank you for the detailed response. I am not objecting to aligning WS-Agreement to other standard WS specs. My objection is specific to the status of WS-Policy. Simply put, we think that standards should build on standards. Not on drafts, public or otherwise. WS-Policy has been submitted to the W3C (a good thing) but this is just the beginning of the standardization process for that spec. Can anyone claim that the final product of the WS-Policy WG will be exactly the same as this initial submission? For me this out weighs any benefit that might be obtained from making a point that should be obvious to people familiar with the specifications anyway. I would like to see the WS-Agreement specification, which already has a number of implementations, published. It's been in draft mode too long. Andreas Asit Dan wrote:
Andreas, We didn't have a discussion on this in our weekly call. As Karl and Toshi noted that this is a trivial change (and Heiko provided a validated schema with this change), so from a pure technical implementation viewpoint this doesn't impact the spec even at this late stage.
I believe this is a very important issue, and we should have a well reasoned and well articulated position on this for the wider audience -- whatever may be the final decision of the group. The issue will keep coming up as the wider audience (Web Services community) will fail to grasp the strong objections of this group to aligning this spec to WS* stack, and WS-Policy in particular. I believe the goal of this group is to make WS-Agreement specification to be adopted by the wider Web Services community, and not to be perceived as something niche for job scheduling or just "Grid-thingy". Off course, in the same spirit, I (we) have equally strongly advocated to the JSDL community for leveraging this spec in specifying flexible scheduling objectives.
There are several benefits from this change: better alignment and acceptance by the broader WS* community and also avoiding confusion on SLA vs Policy. A wide spectrum of folks I hear from in my everyday activities (architects, developers, customers, analysts...) don't quite distinguish SLA and Policy. [ Off course, that's not my position.] Typical comments I hear -- are you using WS-Policy in specifying service level assertions? By embracing the use of WS-Policy as an envelope for agreement terms we not only avoid this confusion but also easily demonstrate what additional aspects are being covered by WS-Ag spec. Finally, in the runtime enforcement environments (service registry, monitoring system, workload manager, ... ) SLA derived enforcement policies can be represented uniformly.
Given that WS-Policy draft (that has been submitted to W3C) is very stable - has been co-authored by representatives from several organizations, already implemented by many vendors and many other OASIS standards on security, transaction, reliability, etc. dependent on this spec - and changes to the current draft of WS-Ag spec is minimal (not surprising, since we started with WS-Policy for term composition), there are many good reasons to embrace WS-Policy now. In any case, it's a public document (W3C), and we can make WS-Ag spec dependent only on the submitted draft.
Regards. Asit Dan, Ph.D. SWG SOA Design Requirements Phone: (914) 766-1767 Internet: asit@us.ibm.com ICSOC 06 PC Chair (http://www.icsoc.org)
*Karl Czajkowski <karlcz@univa.com>* Sent by: owner-graap-wg@ggf.org
06/28/2006 03:20 AM
To Andreas Savva <andreas.savva@jp.fujitsu.com> cc "'GRAAP-WG'" <graap-wg@gridforum.org>, Toshiyuki Nakata <t-nakata@cw.jp.nec.com>, Asit Dan/Watson/IBM@IBMUS Subject Re: [graap-wg] url for the Web Services Policy WG in W3C
I agree. It doesn't seem to add much to WS-Agreement at this point, and I think people who want to engage in an "SLA and policy" discussion should be able to observe the trivial mapping necessary to understand our compositions as policy composition.
karl
On Jun 28, Andreas Savva modulated: ...
I've read Toshi's previous email on pros/cons and I agree with him. I think at this point (one step before publication of the WS-Agreement spec) making a change that brings back a dependency on a specification that is about to enter the standardization process is not a good idea.
-- Andreas Savva
-- Karl Czajkowski karlcz@univa.com
-- Andreas Savva Fujitsu Laboratories Ltd
On Jul 05, Andreas Savva modulated:
Asit,
Thank you for the detailed response.
I am not objecting to aligning WS-Agreement to other standard WS specs. My objection is specific to the status of WS-Policy. Simply put, we think that standards should build on standards. Not on drafts, public or otherwise. WS-Policy has been submitted to the W3C (a good thing) but this is just the beginning of the standardization process for that spec. Can anyone claim that the final product of the WS-Policy WG will be exactly the same as this initial submission? For me this out weighs any benefit that might be obtained from making a point that should be obvious to people familiar with the specifications anyway.
I would like to see the WS-Agreement specification, which already has a number of implementations, published. It's been in draft mode too long.
Andreas
I agree with this sentiment. I also suggest that we not ignore the possibility of a minor "point release" to generate a new updated WS-Agreement spec with new namespaces and possibly this WS-Policy dependency when such a standard is finalized. I think we put too much emphasis on trying to find one perfect snapshot, rather than accepting different snapshots for different purposes. The existing implementors have an interest in standardizing their services. Some of us (like me ;-) expect further experience w/ the first WS-Agreement standard to likely inform changes for a future version, since this whole area is underexplored in practice. Clearly, nobody is advocating that we put out one WS-Agreement spec and then retire forever since it is perfect... karl -- Karl Czajkowski karlcz@univa.com
I know that I'm not a particularly active member of this group any more - nor the most ardent advocate of WS-Agreement ;-) But I have to say that I agree wholeheartedly with Andreas and Karl. This spec really needs to get published, and out into the world as soon as possible. Experience with building real systems is going to be crucial for developing future iterations of the spec. (Anyway, how else will we get to the point where you all realize that I was right about phased commit?) Cheers, Jon. On Jul 5, 2006, at 5:45 AM, Karl Czajkowski wrote:
On Jul 05, Andreas Savva modulated:
Asit,
Thank you for the detailed response.
I am not objecting to aligning WS-Agreement to other standard WS specs. My objection is specific to the status of WS-Policy. Simply put, we think that standards should build on standards. Not on drafts, public or otherwise. WS-Policy has been submitted to the W3C (a good thing) but this is just the beginning of the standardization process for that spec. Can anyone claim that the final product of the WS-Policy WG will be exactly the same as this initial submission? For me this out weighs any benefit that might be obtained from making a point that should be obvious to people familiar with the specifications anyway.
I would like to see the WS-Agreement specification, which already has a number of implementations, published. It's been in draft mode too long.
Andreas
I agree with this sentiment. I also suggest that we not ignore the possibility of a minor "point release" to generate a new updated WS-Agreement spec with new namespaces and possibly this WS-Policy dependency when such a standard is finalized.
I think we put too much emphasis on trying to find one perfect snapshot, rather than accepting different snapshots for different purposes. The existing implementors have an interest in standardizing their services. Some of us (like me ;-) expect further experience w/ the first WS-Agreement standard to likely inform changes for a future version, since this whole area is underexplored in practice.
Clearly, nobody is advocating that we put out one WS-Agreement spec and then retire forever since it is perfect...
karl
-- Karl Czajkowski karlcz@univa.com
Resending ther conflicts... BR Toshi <wsag:Agreement AgreementId=”xsd:string”> Sec.4 P.15 <wsag:Name> xs:NCName </wsag:Name> ? <wsag:AgreementContext> wsag:AgreementContextType </wsag:AgreementContext> <wsag:Terms> wsag:TermCompositorType </wsag:Terms> </wsag:Agreement> <wsag:Term Name=”xsd:NCName?”/> 4.2.1 P.18 <wsag:ServiceDescriptionTerm 4.2.3.1 P.20 wsag:Name=”xs:NCName” wsag:ServiceName=”xs:NCName”> <xsd:any> … </xsd:any> </wsag:ServiceDescriptionTerm> /wsag:ServiceDescriptionTerm/@wsag:Name 4.2.3.1 P.20 The MANDATORY name attribute (of type xs:NCName) represents the name given to a term. <wsag:ServiceReference 4.2.4 P.21 wsag:Name=”xs:NCName” wsag:ServiceName=”xs:NCName”> <xsd:any> … </xsd:any> </wsag:ServiceReference> <wsag:ServiceProperties 4.2.5 P.21 wsag:Name=”xs:NCName” wsag:ServiceName=”xs:NCName”> <wsag:VariableSet>wsag:VariableSetType</wsag:VariableSet> </wsag:ServiceProperties> <wsag:Variable wsag:Name=”xsd:NCName” wsag:Metric=”xsd:QName”> 4.2.5.1 P.22 <wsag:Location>xsd:anyType</wsag:Location> </wsag:Variable> <wsag:GuaranteeTerm Obligated=”wsag:ServiceRoleType”> 4.2.6.1 P.24 <wsag:ServiceScope ServiceName=”xsd:NCName”> xsd:any </wsag:ServiceScope>* <wsag:template TemplateId=”xsd:string”> 5 P.30 <wsag:Name> xs:NCName </wsag:Name> ? <wsag:Item Name=”xsd:NCName”> 5.1.1 P.32 9.4.2 Resource Property wsag:Name P.45 The wsag:Name resource property is of type xsd:NCName. It MAY be empty if no name has been defined in the offer submitted. ** ID being string> <wsag:Agreement AgreementId=”xsd:string”>Sec.4 P.15 <wsag:TemplateId>xsd:string</wsag:TemplateId> Sec. 4.1 P.16 <wsag:template TemplateId=”xsd:string”> Se. 5 P.30 9.4.3 Resource Property wsag:Id P.45 The wsag:Id resource property is of type xsd:string. It MUST be a defined and represents the ID (unique between the parties to the agreement) of the present agreement version. ------- NEC 中央研究所 主席技術主幹 中田 登志之 Toshiyuki Nakata Executive Chief Engineer Central Research Laboratories NEC Corporation +81-44-431-7653
To people who could not attend the telecon.. Apologies for my poor English.. The info below had been for some discussion in the telecon and unfortunately I could not find the peoples' address so sent it to the whole mailing list. So apologies and Best Regards Toshi
Resending ther conflicts...
BR Toshi
<wsag:Agreement AgreementId=”xsd:string”> Sec.4 P.15 <wsag:Name> xs:NCName </wsag:Name> ? <wsag:AgreementContext> wsag:AgreementContextType </wsag:AgreementContext> <wsag:Terms> wsag:TermCompositorType </wsag:Terms> </wsag:Agreement>
<wsag:Term Name=”xsd:NCName?”/> 4.2.1 P.18
<wsag:ServiceDescriptionTerm 4.2.3.1 P.20 wsag:Name=”xs:NCName” wsag:ServiceName=”xs:NCName”> <xsd:any> … </xsd:any> </wsag:ServiceDescriptionTerm>
/wsag:ServiceDescriptionTerm/@wsag:Name 4.2.3.1 P.20 The MANDATORY name attribute (of type xs:NCName) represents the name given to a term.
<wsag:ServiceReference 4.2.4 P.21 wsag:Name=”xs:NCName” wsag:ServiceName=”xs:NCName”> <xsd:any> … </xsd:any> </wsag:ServiceReference>
<wsag:ServiceProperties 4.2.5 P.21 wsag:Name=”xs:NCName” wsag:ServiceName=”xs:NCName”> <wsag:VariableSet>wsag:VariableSetType</wsag:VariableSet> </wsag:ServiceProperties>
<wsag:Variable wsag:Name=”xsd:NCName” wsag:Metric=”xsd:QName”> 4.2.5.1 P.22 <wsag:Location>xsd:anyType</wsag:Location> </wsag:Variable>
<wsag:GuaranteeTerm Obligated=”wsag:ServiceRoleType”> 4.2.6.1 P.24 <wsag:ServiceScope ServiceName=”xsd:NCName”> xsd:any </wsag:ServiceScope>*
<wsag:template TemplateId=”xsd:string”> 5 P.30 <wsag:Name> xs:NCName </wsag:Name> ?
<wsag:Item Name=”xsd:NCName”> 5.1.1 P.32
9.4.2 Resource Property wsag:Name P.45 The wsag:Name resource property is of type xsd:NCName. It MAY be empty if no name has been defined in the offer submitted.
** ID being string> <wsag:Agreement AgreementId=”xsd:string”>Sec.4 P.15
<wsag:TemplateId>xsd:string</wsag:TemplateId> Sec. 4.1 P.16
<wsag:template TemplateId=”xsd:string”> Se. 5 P.30
9.4.3 Resource Property wsag:Id P.45 The wsag:Id resource property is of type xsd:string. It MUST be a defined and represents the ID (unique between the parties to the agreement) of the present agreement version.
------- NEC 中央研究所 主席技術主幹 中田 登志之 Toshiyuki Nakata Executive Chief Engineer Central Research Laboratories NEC Corporation +81-44-431-7653
------- NEC 中央研究所 主席技術主幹 中田 登志之 Toshiyuki Nakata Executive Chief Engineer Central Research Laboratories NEC Corporation +81-44-431-7653
participants (6)
-
Andreas Savva -
Asit Dan -
Jon MacLaren -
Karl Czajkowski -
t-nakata＠cw.jp.nec.com -
Toshiyuki Nakata