RE: Issue 7970

Wu,
  I think you're missing the point.  WS-Eventing needs to allow for more 
than one deployment model - this does not mean that every deployment needs 
to support everything.  Current WS-Eventing only works for one model and 
will not work in many other common models - like clusters.  If you want to 
have your deployment limited to one where only one IP address sends 
notifications then that's great.  But if WS-Eventing is designed so that 
that is the only model then it will severely limited its use in more 
advanced environments.

  If you really want to enforce the rule you have in mind then I suggest 
you open a new issue to add text to WS-Eventing that makes this very 
clear, and clearly define the scope of an Event Source - meaning limited 
to just one outbound IP address so that this can be an explicit statement 
of direction instead of informally implied - leading to confusion and 
interop issues.

thanks
-Doug
______________________________________________________
STSM |  Standards Architect  |  IBM Software Group
(919) 254-6905  |  IBM 444-6905  |  dug@us.ibm.com
The more I'm around some people, the more I like my dog.



"Chou, Wu (Wu)" <wuchou@avaya.com> 
10/26/2009 03:34 PM

To
Doug Davis/Raleigh/IBM@IBMUS
cc
"Bob Freund" <bob.freund@hitachisoftware.com>, "Li, Li (Li)" 
<lli5@avaya.com>, <public-ws-resource-access@w3.org>
Subject
RE: Issue 7970






Doug,
 
Please see the comments in line.
 
Thanks,
 
- Wu Chou.

From: Doug Davis [mailto:dug@us.ibm.com] 
Sent: Monday, October 26, 2009 10:51 AM
To: Chou, Wu (Wu)
Cc: Bob Freund; Li, Li (Li); public-ws-resource-access@w3.org
Subject: Re: Issue 7970


Wu, 
  could you elaborate a bit on your thinking here.  If we went with the 
2nd option (which seemed to be preferred on the call): 
   A Web service that accepts requests to create subscriptions for
  a certain set of notification that might be generated.

what woud need to change in your implementation or what would break in any 
existing implementation?  
 
 <Wu: The security and trusted event source will be affected and break. 
Since the notification source is unknown,  the common IP blocking 
implementation cannot be used to protect the event sink.  The event 
subscriber cannot be sure if the event notification is from a trusted 
endpoint . Moreover, the event subscriber cannot be sure if it can receive 
event notification after a successful event subscription, because if the 
notification  is from some unknown suspicious host not permitted by 
firewall filter, it will be blocked by firewall.> 
 <Wu:  In  WS-E, it describes a model that event source indicates its 
event notification operations in its wsdl (or its notification wsdl to be 
BP compliant).  Not clear if it is appropriate that operations on the 
event source endpoint wsdl are not its own operations but operations from 
some unknown endpoint. This change to the fundamental concept of WS-E may 
take time to learn its full impact, and we prefer not changing it.> 

Also, your point #3 actually might not be true.  If WS-Eventing doesn't 
define an Event Source to allow for other components (anything other than 
the _one_ event source) to send Notifications then an extension spec can't 
do it either since it would be contradicting the base spec.  
<Wu: It could work, since the base spec says the notification is from the 
event source, and the extension spec says an event source can be a proxy 
that forwards the event notification to the sink. From the subscriber 
perspective, it is the base  spec, and from the event source perspective, 
it allows an notification source to establish a proxy relation and allow 
subscribers to subscribe events from its proxy.  In short, an extension 
service can allow introducing additional entities and in this case, an 
extended event sender does not need to correspond to any concepts in 
WS-E.>

As it currently stands we have an inconsistency in the spec - if Event 
Sources are the only things that can send Notifications, then when we use 
a pull-style model we're broken because in those cases the Subscription 
Manager is the one that sends the Notifications.   
 <Wu: No, in  ws-eventing, subscription manager and event source can be 
the same endpoint. It should work for your case. Allowing the new changes 
as in the proposal may actually break a pull-model, as the event sender 
can be some unknown thing other than the event source and subscription 
manager. In this case, the event sink does not know where to pull event 
from.> 
 I don't think the above proposal would break anyone, nor even require a 
coding change.  Rather its just an admission that our WS-* specs only 
control what goes on the wire and we can't control what happens behind the 
scenes.  How people choose to implement this stuff is up to them.  For 
example, there is nothing inWS-Addressing that requires the sender of an 
async response to be the same entity as the one that received the request 
and this is no different.  Do we really need to say that the entity that 
sends the SubscribeResponse MUST be the same one the receives the 
SubscribeRequest?   
 <Wu: One difference is: in ws-eventing, the event source has notification 
operations in its wsdl (or its notification wsdl) and the subscriber 
subscribes to that service from that (event source) endpoint.  It is true 
that WS-A does not prohibit a reply comes from somewhere other than the 
receiver, but the WS-A only specifies how a receiver  formulates a reply 
message (WS-A core section 3.4). It seems other use cases are extensions.> 

 And what does "same one" mean?  In a clustered environment things get a 
bit complicated. 

thanks
-Doug
______________________________________________________
STSM |  Standards Architect  |  IBM Software Group
(919) 254-6905  |  IBM 444-6905  |  dug@us.ibm.com
The more I'm around some people, the more I like my dog. 



"Chou, Wu (Wu)" <wuchou@avaya.com> 
Sent by: public-ws-resource-access-request@w3.org 
10/26/2009 10:23 AM 


To
"Bob Freund" <bob.freund@hitachisoftware.com>, 
<public-ws-resource-access@w3.org>, 
<public-ws-resource-access-request@w3.org> 
cc
"Li, Li (Li)" <lli5@avaya.com> 
Subject
Issue 7970








Bob, 
We see some problems with issue 7970 [1] and we share our thoughts below. 
1) Current WS-Eventing is based on a set of well-defined web services 
(source, sink, subscriber and subscription manager). If there is some 
entity that interacts with WS-Eventing services, it should be either 
defined in the spec, or it should be out of scope. This proposal involves 
interactions with some entity whose behavior is not defined in the spec. 
2) By allowing an unknown third-party (instead of event source) to send 
notifications to event sink complicates security checks against attacks to 
the event sink. For example, IP blocking would not work since the true 
notification senders are unknown, even after the subscription. 
3) Current WS-Eventing architecture can handle this use case by having the 
event source forward notifications (from other senders) to the sinks. 
Therefore, alternative approaches should be treated as extensions. 
Thanks, 
- Wu Chou/Li Li, 
[1] http://www.w3.org/Bugs/Public/show_bug.cgi?id=7970