Merge "Clairify notification related architecture"

diff --cc requirements/03-architecture.rst
index 82a13f0,26c864a..1b05935
--- 1/requirements/03-architecture.rst
--- 2/requirements/03-architecture.rst
+++ b/requirements/03-architecture.rst
@@@ -158,30 -157,20 +158,34 @@@ would lead to heavy signaling traffic. 
  messaging model is better suited for these notifications, as notifications are
  only sent to subscribed consumers.
  
- Note: the VIM should only accept individual notification URLs for each resource
+ Notifications will be send out along with the configuration by the consumer.
+ The configuration includes endpoint(s) in which the consumers can specify
+ multiple targets for the notification subscription, so that various and
+ multiple receiver functions can consume the notification message.
+ Also, the conditions for notifications shall be configurable, such that
+ the consumer can set according policies, e.g. whether it wants to receive
+ fault notifications or not.
+ 
+ Note: the VIM should only accept notification subscriptions for each resource
  by its owner or administrator.
- 
  Notifications to the Consumer about the unavailability of virtualized
  resources will include a description of the fault, preferably with sufficient
- abstraction rather than detailed physical fault information. Flexibility in
- notifications is important. For example, the receiver function in the
- consumer-side implementation could have different schema, location, and policies
- (e.g. receive or not, aggregate events with the same cause, etc.).
+ abstraction rather than detailed physical fault information.
  
 +.. _fencing:
 +
 +Fencing
 +^^^^^^^
 +Recovery actions, e.g. safe VM evacuation, have to be preceded by fencing the
 +failed host. Fencing hereby means to isolate or shut down a faulty resource.
 +Without fencing -- when the perceived disconnection is due to some transient
 +or partial failure -- the evacuation might lead into two identical instances
 +running together and having a dangerous conflict.
 +
 +There is a cross-project effort in OpenStack ongoing to implement fencing. A
 +general description of fencing in OpenStack is available here:
 +https://wiki.openstack.org/wiki/Fencing_Instances_of_an_Unreachable_Host .
 +
  Recovery Action
  ^^^^^^^^^^^^^^^